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(54) Controlling devices on a network through policies 



(57) A system that facilitates control over a group of 
devices coupled to a network. This system allows an op- 
erator to specify a policy for controlling a group of de- 
vices. This policy is automatically translated into lower- 
level device-specific commands, which are sent to the 
devices across the network. The system additionally 
provides a mechanism for continuous monitoring and 
control of the devices. Thus, one embodiment of the 
present invention provides a system for controlling de- 
vices on a network. This system operates by receiving 
a request to define a policy for controlling the devices. 



In response to the request, the system creates a policy 
object specifying actions of the devices to implement the 
policy, and stores the policy object in a memory. Next, 
the system associates the policy object with devices 
from the network, and controls these associated devices 
automatically according to actions specified in the policy 
object. In one embodiment of the present invention, dur- 
ing creation of the policy object, the system translates 
the policy into device-specific commands for controlling 
the devices on the network, and associates the device- 
specific commands with the policy object. 
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Description 

BACKGROUND 
Field of the Invention 

[0001 ] The present invention relates to controlling de- 
vices across a computer network. More specifically, the 
present invention relates to providing an infrastructure 
that allows a user to specify a policy to govern the op- 
eration of devices coupled to a computer network. 

Related Art 

[0002] In addition to facilitating communications be- 
tween computer systems, computer networks are in- 
creasingly being used to facilitate communications be- 
tween computer systems and electrical or mechanic*! 
uevices sucn as network routers, primers, lacsimiie ma- 
chines, PBX systems, photocopiers and audio/visual 
equipment. For example, computer networks make it 
possible for computer systems to control and coordinate 
the actions of switching equipment in a PBX system, or 
to remotely control the operation of a routers in a com- 
puter network. 

[0003] However, the mechanisms being used to con- 
trol such devices are presently very unsophisticated, 
which creates a number of problems for a system oper- 
ator desiring to control a group of devices. First, devices 
are typically controlled by sending low-level device-spe- 
cific commands to the devices. Thus, in order to control 
such devices a system operator must learn these low- 
level device-specific commands. Second, devices are 
typically controlled individually. Hence, in order to con- 
trol a group of devices, a system operator must explicitly 
send commands to individual devices in the group. This 
can be a time-consuming process. Third, different de- 
vices are typically controlled through different manage- 
ment interfaces. Hence, a system operator must use a 
number of different management interfaces to operate 
i> I;' ---.^ " '--c. .-.ri^,)', pr^^t;. it sy^^ms Jo iiul pro- 
vide automated mechanisms to control and monitor the 
actions of devices. Consequently, a system operator 
must manually monitor and control the devices in order 
to accomplish a task requiring periodic monitoring and 
control. 

[0004] What is needed is a system that provides high- 
level control over a group of devices coupled to a com- 
puter network. 

SUMMARY 

[0005] One aspect of the present invention provides 
a system that facilitates high-level control over a group 
of devices coupled to a computer network. This system 
allows an operator to specify a high-level policy for con- 
trolling a group of devices. This high-level policy is au- 
tomatically translated into lower-level device-specific 



commands, which are sent to the devices across the 
computer network. The system additionally provides a 
mechanism for continuous monitoring and control of the 
devices. Thus, one embodiment of the present invention 

5 provides a system for controlling devices on a network. 
This system operates by receiving a request to define a 
policy for controlling the devices. In response to the re- 
quest, the system creates a policy object specifying ac- 
tions of the devices to implement the policy, and stores 

io the policy object in a memory. Next, the system associ- 
ates the policy object with devices from the network, and 
controls these associated devices automatically accord- 
ing to actions specified in the policy object. In one em- 
bodiment of the present invention, during creation of the 

is policy object, the system translates the policy into de- 
vice-specific commands for controlling the devices on 
the network, and associates the device-specific com- 
mands with the poHr" ob'-rt 

[OUObj Fuiiher aspects of the invention ate exempii- 
20 fjed by the attached claims. 

BRIEF DESCRIPTION OF THE FIGURES 

[0007] FIG. 1 illustrates a system including computers 
2S and devices coupled together through a network in ac- 
cordance with an embodiment of the present invention. 
[0008] FIG. 2 illustrates the internal structure of a pol- 
icy server for controlling devices on a network in accord- 
ance with an embodiment of the present invention. 
30 [0009] FIG. 3 illustrates the internal structure of a da- 
tabase system that stores dynamic entries specifying 
actions for devices on a network in accordance with an 
embodiment of the present invention. 
[0010] FIG. 4 is a flow chart illustrating the process of 
35 creating a policy for controlling devices on a network in 
accordance with an embodiment of the present inven- 
tion. 

[0011] FIG. 5 is a flowchart illustrating the process of 
modifying a policy in accordance with an embodiment 

40 of the present invention. 

lJ0 J^j t »G. 5 *3 a no/.- ^iictrt i'tusiiatmg ihe process of 
monitoring devices in accordance with an embodiment 
of the present invention. 

[0013] FIG. 7 is a flow chart illustrating the process of 
4 $ deleting a policy in accordance with an embodiment of 
the present invention. 

[0014] FIG. 8 is a block diagram illustrating an exam- 
ple of controlling devices that route data across a net- 
work in accordance with an embodiment of the present 
50 invention. 



DETAILED DESCRIPTION 

[0015] The fol towing description is presented to ena- 
55 ble any person skilled in the art to make and use the 
invention, and is provided in the context of a particular 
application and its requirements. Various modifications 
to the disclosed embodiments will be readily apparent 
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to those skilled in the art, and the general principles de- 
fined herein may be applied to other embodiments and 
applications without departing from the spirit and scope 
of the present invention. Thus, the present invention is 
not intended to be limited to the embodiments shown, 
but is to be accorded the widest scope consistent with 
the principles and features disclosed herein. 

Description of System 

[0016] FIG. 1 illustrates a system including computers 
and devices coupled together through a network 108 in 
accordance with an embodiment of the present inven- 
tion. The system illustrated in FIG. 1 includes network 
108, which is coupled to clients 102, 104 and 106 as 
well as servers 118 and 120. Network 108 is additionally 
coupled to devices 130 and 132 and policy server 122. 
f0017l Network 108 qeneralfv refers to anv tvpe of 
vv it e ui wifeless uhk uciwetsii compuieis anci device^, 
including, but not limited to, a local area network, a wide 
area network, or a combination of networks. In one em- 
bodiment of the present invention, network 108 includes 
the Internet. In the embodiment illustrated in FIG. 1 , net- 
work 108 includes backbone 114, server network 116 
and access networks 110 and 112. 
[001 8] Access networks 1 1 0 and 1 1 2 may include any 
type of network that can be used to couple client com- 
puting systems 1 02, 1 04 and 1 06 with network 1 08. This 
includes, but is not limited to local area networks. More 
specifically, access network 110 couples clients 102 and 
104. with backbone 114, and access network 112 cou- 
ples client 106 to backbone 114. 
[0019] Backbone 114 includes switching and routing 
devices that facilitate communications between server 
network 116 and access networks 110 and 112. This in- 
cludes, but is not limited to, local area networks and wide 
area networks. For example, backbone 114 may include 
the Internet. The switching and routing devices in back- 
bone 1 1 4 are denoted by boxes containing X's, and can 
be controlled by commands sent from computer sys- 

[0020] Server network 116 couples backbone 114 
with servers 118 and 120 as well as devices 130 and 
132. Server network 116 similarly contains switching 
and routing devices denoted by boxes containing X's 
that can be controlled by commands from computer sys- 
tems coupled to network 108. Server network 116 may 
be any type of network coupled to a server computer 
system. For example, server network 116 may include 
a network supported by an Internet Service Provider 
(ISP). 

[0021] Clients 102, 104 and 106 may include any 
node on a computer network including computational 
capability and including a mechanism for communicat- 
ing across network 108. For example, clients 102, 104 
and 106 may include a Java™ workstation or a personal 
computer running an Internet browser. 
[0022] Servers 1 1 8 and 1 20 may include any node on 



a computer network including computational capability, 
and possibly data storage capability, as well as a mech- 
anism for servicing requests from clients for computa- 
tional or data storage resources. More specifically, serv- 

s er 118 is a file server that services requests for file ac- 
cesses using the Network File System (NFS) protocol, 
and server 120 is a database server that services re- 
quests for database operations. 
[0023] Devices 1 30 and 1 32 may include any device 

10 that can be controlled by commands sent over a com- 
puter network. This includes, but is not limited to, a print- 
er, a facsimile machine, a PBX telephone exchange, a 
photocopier, or audio/visual equipment, such as a digital 
camera. Note that although devices 130 and 132 are 

is illustrated as being coupled to server network 1 1 6, they 
may generally be coupled to any location on network 
108. 

roo?4i PoMcv sr'ver 1 22 rec^'^scommpnd^ from us- 
ti 'liu ihrougn Giaphicai User i menace (CaUl) 124, and 
20 uses these commands to control the actions of devices 
coupled to network 108. As illustrated in FIG. 1, policy 
server 122 includes processor 121 and memory 123, 
which are used to carry out the actions of policy server 
122. 

2S [0025] The system illustrated in FIG. 1 operates as fol- 
lows. First, user 126 inputs commands into GUI 124; 
these commands specify a high-level policy for control- 
ling actions of devices 1 30 and 1 32. For example, a pol- 
icy may specify that a temperature control system 

30 should keep a portion of a building at a certain temper- 
ature. Another policy may specify that a network man- 
agement system should allow no more than 30% of total 
bandwidth for video traffic. Yet another policy may spec- 
ify that a network management system should give high- 

3S er priority to traffic on a LAN that originates from a fi- 
nance server at the end of a quarter. Next, policy server 
122 receives these commands and translates them into 
low-level device-specific commands that are sent to de- 
vices 103 and 1 32 across network 108. Note that policy 

40 server 1 22 may additionally be used to control switching 
l.j)J roji*ng^3wces :^i:ar\ ju^o^e 1 1 4 ana ser /ot net- 
work 116. 

Description of Policy Server 

45 

[0026] FIG. 2 illustrates the internal structure of a pol- 
icy server 122 from FIG. 1 in accordance with an em- 
bodiment of the present invention. As in FIG. 1, policy 
server 1 22 receives policies from user 1 26 through GUI 

50 124. These policies are translated into lower-level de- 
vice specific commands that are sent over network 108 
to devices 130 and 132 (illustrated in FIG. 1). Policy 
server 1 22 receives requests to create policies 202 and 
204, through HTTP protocol interface 206, or LDAP pro- 

55 tocol interface 208. HTTP protocol interface 206 con- 
tains computational resources to decipher commands 
in the HTTP protocol. LDAP protocol interface 208 con- 
tains computational resources for deciphering com- 
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mands in the LDAP protocol. 

[0027] Policy server 122 additionally contains direc- 
tory 210, which is a data storage area that can be used 
to store dynamic entries, which specify parameters for 
different policies. In one embodiment of the present in- 5 
vention, directory 210 additionally stores conventional 
static database entries containing static data. 
[0028] Storing a dynamic entry in directory 210 caus- 
es policy factory 250 to create a corresponding policy 
object, which is stored in policy storage area 220. In the 10 
illustrated embodiment, policy storage area 220 con- 
tains policy objects 221 , 222, 223, 224, 225 and 226. In 
one embodiment of the present invention these policy 
objects includes objects defined within an object-orient- 
ed programming system, which include data and meth- is 
ods that can be invoked to implement the associated 
policy. 

T0029] Policy obiects 221. 22? ??3. 22* 295 and 226 
coMrnunicaie with Devices ihrougn aevicc r-oiicy Pro- 
gramming Interface (device PPI) 230. Device PPI 230 20 
provides a uniform interface for communicating with de- 
vices across network 108. To this end, device PPI 230 
includes a number of adapters for communicating with 
different devices using device-specific protocols. In gen- 
eral, device PPI 230 includes a different adapter for 2s 
each different type of device it communicates with. More 
particularly, device PPI 230 includes: device adapter 
231 for communicating with NFS devices; device adapt- 
er 233 for communicating with database devices; and 
device adapter 235 for communicating with web server 30 
devices. As illustrated in FIG. 2, device PPI 230 can ad- 
ditionally communicate directly across network 108 
through communication link 236. 
[0030] Device adapters 231 , 233 and 235 include de- 
vice objects 232, 234 and 236, respectively. Device ob- 35 
jects 232, 234 and 236 contain data and methods that 
can be used to communicate with associated devices 
over network 108. These device objects are created by 
device factory 250 as is described below. 
[0031] Policy server 1 22 additionally includes topolo- *o 



^e:v;co ^uy, 



vcops iujk o. ma uc.icas ana 



computing nodes that are coupled to network 1 08. This 
information allows policies within policy server 122 to 
adapt to changes in the topology of network 108. 

Description of Database System 



45 



[0032] FIG. 3 illustrates a database system that stores 
dynamic entries specifying actions of devices on net- 
work 108 in accordance with an embodiment of the so 
present invention. In one embodiment of the present in- 
vention, this database system is used to implement di- 
rectory 210 from FIG. 2. The information stored in the 
directory is composed of directory of entries. Each entry 
is made up of attributes, wherein each attribute includes ss 
a type and one or more values. The type of attribute that 
is present in a particular entry is dependent on the class 
of object the entry describes. 



[0033] FIG. 3 illustrates a directory structured in the 
form of a tree, with vertices representing the entries. En- 
tries higher in the tree (nearer the root) represent objects 
such as countries or organizations, whereas entries low- 
er in the tree represent people or application-specific ob- 
jects. Entries can include a distinguished name, which 
uniquely identifies the entry. The distinguished name of 
an entry could be made up of the distinguished name of 
its superior entry together with specially nominated at- 
tribute values from the entry. 

[0034] In one embodiment of the present invention, 
the Lightweight Directory Access Protocol (LDAP) is 
used the access the directory. The LDAP directory en- 
forces a set of rules to ensure that the database remains 
well-formed in the face of modifications over time. These 
rules, known as the LDAP directory schema, prevent an 
entry from having the wrong types of attributes for its 
obiect class. They also prevent attrihi ftp vaKm? f ron 
ing 01 me wrong form lor me aunbute type, and even 
prevent entries from having subordinate entries of the 
wrong class. 

[0035] In order to implement the present invention, 
the LDAP directory is extended to contain statements of 
dynamic behavior about devices coupled to network 
1 08. These statements of dynamic behavior are referred 
to as policies. Entries that represent policies are differ- 
ent from conventional directory entries in that they have 
a special class or schema definition to represent them. 
An LDAP directory entry that includes a policy requires 
more than standard functions for storage and retrieval. 
It requires a function that takes actions that are dictated 
by the attributes of the policy entry. 
[0036] As is illustrated in FIG. 3, the directory struc- 
ture includes a root node 300, which is coupled to entries 
302 and 304. Entry 302 is coupled to entries 306 and 
308. Entry 306 is coupled to entry 310. These entries 
contain conventional static data. More importantly entry 
304 is coupled to policy root object 312. Policy root ob- 
ject 312 forms the root of a tree that contains policy en- 
tries. In the example illustrated in FIG. 3. oolicv root ob- 
jeu J 12 CG-p;3U io policy driirico j 14 aiiO Sid. 
[0037] As illustrated in FIG. 3, policy entry 316 in- 
cludes attributes 317, 318 and 31 9. Each policy attribute 
contains a type and values. For example, policy attribute 
31 7 includes type 320 and values 322. 

Description of Policy Creation Process 

[0038] FIG. 4 is a flow chart illustrating the process of 
creating a policy for controlling devices in accordance 
with an embodiment of the present invention. The proc- 
ess starts when the system receives a request to create 
at policy (state 402). In one embodiment of the present 
invention, the request is received from user 126 who in- 
puts the request into a web browser operating on GUI 
124. The request can be received in a number of ways. 
In one embodiment of the present invention, the system 
receives the policy creation request through HTTP pro- 
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tocol interface 206. In another embodiment of the 
present invention, the system receives the request 
through LDAP protocol interface 208. 
[0039] The system next adds an entry for the request- 
ed policy in directory 210 within policy server 1 22 (state 
404). This entry contains attributes specifying the policy. 
Next, a corresponding policy object is created by policy 
factory 240 (state 406), and the policy object is stored 
in policy storage area 220. This policy object contains 
data and methods for controlling devices on network 
108 to implement the policy. In one embodiment of the 
present invention, the object is created within the Java™ 
programming language based upon the Java™ class 
path of the policy. 

[0040] Next, the policy object performs a lookup in di- 
rectory 210 to verify that the object has been created 
consistently with the associated parameters contained 
within the corresponding entry in directory 200 Estate 
406). Nexi, ihe oojeci acknowledges mat n oeen 
created successfully by sending a message to user 1 26 
through GUI 124 (state 410). 

[0041] The policy object next fetches a list of devices 
that compose the policy domain from topology service 
260 (state 412). Topology service 260 maintains status 
information for the active devices coupled to the network 
by either periodically polling devices on network 108, or 
by merely listening to traffic on network 1 08 to determine 
which devices are responding to commands, and are 
hence, "active. * During this process, topology service 
260 updates the corresponding policy entry in directory 
210 to reflect and changes in the policy domain. Once 
the policy object knows the status of devices, it can se- 
lect devices to implement the policy from the policy do- 
main. 

[0042] In order to communicate with and command 
the devices, the policy object fetches device object han- 
dles from device factory 250 (state 41 4). Next, the policy 
object uses the device object handles to communicate 
with the devices in order to establish and monitor the 
policy according to the policy schedule (state 416). This 



vice PPI 230 and device objects 232, 234 and 236, as 
well as device adapters 231 , 233 and 235. 
[0043] Finally, the policy object updates its corre- 
sponding entry in directory 210 to indicate the status of 
the policy (state 418). This information includes a list of 
the devices involved in implementing the policy as well 
as status informalion for the devices and the policy. This 
updating process occurs periodically while the policy is 
executing, so that the corresponding entry in directory 
210 is continually updated. 

[0044] The above states are repeated for each addi- 
tional policy object that is created by the system illus- 
trated in FIG. 2. 

Description of Policy Modification Process 
[0045] FIG. 5 is a flow chart illustrating the process of 



modifying an existing policy in accordance with an em- 
bodiment of the present invention. The process starts 
when the system receives a request to modify an exist- 
ing policy (state 502). In one embodiment of the present 
5 invention, the request is received from user 1 26 who in- 
puts the request into a web browser operating on GUI 
124. Next, the system modifies the entry for the policy 
within directory 210, so that the directory properly indi- 
cates the modified state of the policy (state 504). Next, 
10 the system modifies the policy object by sending a 
change request to policy factory 240 (state 505). Policy 
factory 240 relays this request to the policy object, which 
makes the requested change. Next, the policy object 
performs a lookup in directory 210 to verify that the pol- 
is icy object has been modified consistently with the asso- 
ciated parameters contained within the corresponding 
entry in directory 200 (state 508). Next, the policy object 
acknowledges that it ha? been modified successfully by 
senotng a message io usei \ Zo inrougn GUI 1 2*+ (siaie 
20 510). The above process is repealed whenever a policy 
is modified. 

Description of Device Monitoring Process 

25 [0046] FIG. 6 is a flow chart illustrating the process of 
monitoring devices involved in a policy in accordance 
with an embodiment of the present invention. The proc- 
ess starts when the system receives a request to mon- 
itor an existing policy (state 602). In one embodiment of 
30 the present invention, the request is received from user 
1 26 who inputs the request into a web browser operating 
on GUI 124. Next, the system reads policy status infor- 
mation from the entry for the policy in directory 210 
(state 604). Recall that the entry for the policy in direc- 
ts tory 210 is periodically updated with status information 
regarding the policy. Next, the system returns the policy 
status information to the requestor. In one embodiment 
of the present invention, this status information is re- 
turned in the form of HTML data, which contains Java™ 
40 applets. These Java™ applets query the policy object 

is repeated whenever a request for policy status is re- 
ceived. 

45 Description of Policy Deletion Process 

[0047] FIG. 7 is a flow chart illustrating the process of 
deleting a policy in accordance with an embodiment of 
the present invention. The process starts when the sys- 

50 tern receives a request to delete an existing policy (state . 
702). In one embodiment of the present invention, the 
request is received from user 126 who inputs the re- 
quest into a web browser operating on GUI 124. Next, 
the system initiates the removal process (state 704). 

55 This is accomplished by sending a removal request to 
policy factory 240. Policy factory 240 looks up the cor- 
responding policy object and notifies the policy object 
that it is to be removed. The policy object then carries 



9 

out the removal process and acknowledges that it has 
been successfully deleted by sending a message to us- 
er 126 through GUI 124 (state 706). Next, the system 
removes the entry for the policy from directory 21 0 (state 
708). The above process is repeated whenever a policy s 
is modified. 

Example 

[0048] FIG. 8 is a block diagram illustrating the proc- 10 
ess of controlling devices that route data across a net- 
work in accordance with an embodiment of the present 
invention. In the example illustrated in FIG. 8, policy 
server 1 22 (from FIG. 1 ) controls the actions of a number 
of devices, including server 1 1 8, switch 802, router 804, * 5 
router 805, switch 806 and client 808. Switches 802 and 
806 forward packets at the medium access control level, 
and routers 80a and forward packets at the Internet pro- 

FIG. 1. 20 
[0049] In order to communicate with the illustrated de- 
vices, policy server 122 includes a number of adapters, 
including NFS adapter 81 2 for communicating with serv- 
er 11 B, router adapter 81 4 for communicating with rout- 
ers 804 and 805, and switch adapter 81 6 for communi- 25 
eating with switches 802 and 806. 
[0050] In the configuration illustrated in FIG. 1, policy 
server 122 can implement a number of policies related 
to controlling network traffic between server 118 and cli- 
ent 808. For example, one policy might be to reserve 5 30 
megabits of bandwidth from server 118 to client 808. To 
implement this policy, policy server 122 sends com- 
mands to the illustrated devices from left to right in FIG. 
8 starting at server 118 and proceeding to client 808. 
These commands specify that 5 megabits of bandwidth 3$ 
should be reserved for traffic between server 118 and 
client 808. The reason policy server 122 starts on the 
server side of the network is that network traffic tends 
to be concentrated nearer to file servers, and devices 
that are closer to the file servers tend to include more 40 

[0051] The foregoing descriptions of embodiments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit the invention to the forms dis- 45 
closed. Accordingly, many modifications and variations 
will be apparent to practitioners skilled in the art. Addi- 
tionally, the above disclosure is not intended to limit the 
invention. 



Claims 

1 . A method for controlling devices on a network, com- 
prising: 55 

receiving a request to define a policy specifying 
a behavior for controlling the devices on the 



10 

network; 

creating a policy object specifying actions of the 
devices on the network to implement the policy; 
storing the policy object in a memory; 
associating the stored policy object with at least 
one device from the devices on the network; 
and 

controlling the at least one device in accord- 
ance with the stored policy object in order to 
implement the policy. 

2. The method of claim 1 , wherein the act of creating 
the policy object includes translating the policy into 
device-specific commands for controlling the devic- 
es on the network, and associating the device-spe- 
cific commands with the policy object. 

3. The m^hod of claim ? w h e ra ?n th» act o f controlling 
the at least one oevice mciuoes communicating the 
device-specific commands across the network lo 
the at least one device. 

4. The method of claim 1 , 2 or 3, wherein the act of 
controlling the at least one device includes monitor- 
ing a status of the at least one device. 

5. The method of any preceding claim, wherein the act 
of controlling the at least one device includes per- 
forming a sequence of actions over a period of time 
to implement the policy without human intervention. 

6. The method of any preceding claim, wherein the act 
of controlling the at least one device includes per- 
forming a sequence of actions that are specified in 
relation to a time base. 

7. The method of any preceding claim, further com- 
prising determining which devices are active on the 
network. 

o. T nicicjci ui»y preceJliig ci^i.n, wherein [he act 
of storing the policy object in the memory involves 
storing the policy object in a database. 

9. The method of any preceding claim, wherein the act 
of storing the policy object in the memory involves 
storing the policy object in a random access mem- 
ory. 

10. The method of any preceding claim, wherein the 
policy object includes an object defined within an 
object-oriented programming system. 

1 1 . The method of any preceding claim, wherein the de- 
vices respond to different device-specific com- 
mands. 

12. The method of any preceding claim, wherein the at 
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least one device includes a router for routing traffic 
over the network. 

1 3. A method for controlling devices on a network, com- 
prising: 

receiving a request to define a policy specifying 
a behavior for controlling the devices on the 
network; 

creating a policy object specifying actions of the 
devices on the network to implement the policy, 
including translating the policy into device-spe- 
cific commands for controlling the devices on 
the network, and associating the device-specif- 
ic commands with the policy object; 
storing the policy object in a memory; 
associating the stored policy object with at least 
one device from the devices on the network: 
and 

controlling the at least one device in accord- 
ance with the stored policy object in order to 
implement the policy by communicating the de- 
vice-specific commands across the network to 
the at least one device, and monitoring a status 
of the at least one device. 

14. A computer readable storage medium storing in- 
structions that when executed by a computer cause 
the computerto perform a method for controlling de- 
vices on a network, comprising: 

receiving a request to define a policy specifying 
a behavior for controlling the devices on the 
network; 

creating a policy object specifying actions of the 
devices on the network to implement the policy; 
storing the policy object in a memory; 
associating the stored policy object with at least 
one device from the devices on the network; 
and 

com roiling ihe at least one device in accord- 
ance with the stored policy object in order to 
implement the policy. 

15. A computer instruction signal embodied in a carrier 
wave carrying instructions that when executed by a 
computer cause the computer to perform a method 
for controlling devices on a network, comprising: 



controlling the at least one device in accord- 
ance with the stored policy object in order to 
implement the policy. 

s 16. A system that uses policies to control devices on a 
network, comprising: 

a policy server coupled to the network; 
a request receiving mechanism, within the pol- 
io icy server, that receives a request to define a 
policy specifying a behavior for controlling the 
devices on the network; 
a policy creation mechanism, within the policy 
server, that creates a policy object specifying 
75 actions of the devices on the network to imple- 
ment the policy; 

a memory, in communication with the policy 

creation mechanism. t^? f sice* the n^'iry ob- 
ject; and 

20 an execution mechanism, within the policy 

server, that controls the devices in accordance 
with the stored policy object in order to imple- 
ment the policy. 

2S 17. The system of claim 16, wherein the policy creation 
mechanism translates the policy into device-specif- 
ic commands for controlling the devices on the net- 
work, and associates the device-specific com- 
mands with the policy object. 

30 

18. The system of claim 17, wherein the execution 
mechanism is configured to communicate the de- 
vice-specific commands across the network to de- 
vices. 

35 

19. The system of claim 16, 17 or 18, wherein the exe- 
cution mechanism is configured to monitor status of 
devices on the network. 

4 o 20. The svstem of any ons of c'pims 16 to 19, "/^r^in 
ine execution mechanism is configured to perform 
a sequence of actions over a period of time to im- 
plement the policy without human intervention. 

45 21. The system of any one of claims 16 to 20, wherein 
the execution mechanism is configured to perform 
a sequence of actions that are specified in relation 
to a time base. 



25 17. 



30 

18. 



35 

19. 



receiving a request to define a policy specifying 
a behavbr for controlling the devices on the 
network; 

creating a policy object specifying actions of the 
devices on the network to implement the policy; 
storing the policy object in a memory; 
associating the stored policy object with at least 
one device from the devices on the network; 
and 



The system of any one of claims 16 to 21, further 
comprising a device finding mechanism that deter- 
mines which devices are active on the network. 

The system of any one of claims 16 to 22, wherein 
the memory includes a database. 

24. The system of any one of claims 16 to 23, wherein 
the memory includes a random access memory. 



so 22. 



23. 



55 



13 



EP 0 973 296 A2 



25. The system of any one of claims 16 to 24, wherein 
the policy object includes an object defined within 
a object-oriented programming system. 

26. The system of any one of claims 16 to 25, wherein s 
the devices respond to different device-specific 
commands. 

27. The system of any one of claims 16 to 26, wherein 

the devices include a router for routing traffic over 10 
the network. 
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